Skip to content

fix(doctor): probe real provider binary (claude/codex), not the provider key - #24

Open
dk96-creator wants to merge 1 commit into
amadad:mainfrom
dk96-creator:fix/doctor-checks-real-binary-name
Open

fix(doctor): probe real provider binary (claude/codex), not the provider key#24
dk96-creator wants to merge 1 commit into
amadad:mainfrom
dk96-creator:fix/doctor-checks-real-binary-name

Conversation

@dk96-creator

Copy link
Copy Markdown

Problem

mirofish doctor reports [FAIL] claude-cli binary on PATH on machines where MiroFish actually runs fine.

The check in app/cli.py calls shutil.which(Config.LLM_PROVIDER), but LLM_PROVIDER is the provider key (claude-cli / codex-cli), not a binary name. No binary named claude-cli exists — app/utils/llm_client.py shells out to claude and codex. So doctor fails even though the real LLM call path resolves the binary correctly.

Fix

Translate the provider key to its real binary name (claude-cliclaude, codex-clicodex) before the shutil.which probe, and label the check row with the resolved binary name.

Verification

With claude v2.x on PATH:

  • Before: [FAIL] claude-cli binary on PATH
  • After: [PASS] claude binary on PATHdoctor: all checks passed, exit 0

🤖 Generated with Claude Code

…der key

`mirofish doctor` checked shutil.which(LLM_PROVIDER) — i.e. it looked for a
binary literally named "claude-cli"/"codex-cli". Those binaries don't exist;
the LLM client (app/utils/llm_client.py) shells out to "claude"/"codex". So
doctor reported `[FAIL] claude-cli binary on PATH` even on a correctly
configured machine where the tool runs fine.

Map the provider key to its real binary name before the PATH probe.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant